Plugin extensible xblock services#927
Conversation
|
Thanks for the pull request, @felipemontoya! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
35dbbd5 to
ea3e7b0
Compare
|
@bradenmacdonald @symbolist @pdpinch as fellow maintainers of the xblock library, what do you think about this? |
Henrrypg
left a comment
There was a problem hiding this comment.
Hey folks, i was playing a bit with this implementation and i like it!
Here we have an example of how it could work with ora :) a quick test only adding suggestions as a raw text, but we definitively can go deeper
Screencast.from.12-06-26.17.08.11.webm
| **Why the ``needs``/``wants`` gate stays in front.** The declaration check | ||
| runs before any entry-point lookup, so a plugin-provided service is only ever | ||
| handed to blocks that explicitly asked for it. ``wants`` gives blocks a | ||
| portable soft-dependency: the same block works on installs with and without | ||
| the providing package, enabling features conditionally. |
There was a problem hiding this comment.
I can understand why we have a needs declaration (to show an appropriate error when a required service is not available). But I never understood the point of declaring wants. It just seems like pointless boilerplate.
"We don't allow XBlocks to access a service unless they declare it with needs/wants, because if they don't declare it, ___" What? It would still work totally fine if every XBlock implicitly wants every service, without having to declare them.
This PR adds the capability for openedx plugins to add services to the xblock_runtime. This is needed to be able to offer xblocks (e.g: ORA) capabilities from inside a platform plugin (e.g: openedx-ai-extensions) in a way that does not create a dependency hell and lets the xblock respond gracefully when the service is not present.
References: